NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9611

Internet Message Format | 1996-08-05 | 5.2 KB

Path: misery.millcomm.com!usenet
From: [e-mail] (Dan Hicks)
Newsgroups: comp.lang.misc,comp.lang.c,comp.lang.pl1
Subject: Re: GOTO controversy
Date: 12 Mar 1996 05:00:58 GMT
Organization: Millennium Communications, Inc.
Message-ID: <4i30ea$[e-mail]>
References: <[e-mail]> <4grt4e$[e-mail]> <4hl8mt$[e-mail]> <4hlg11$[e-mail]> <4hpits$[e-mail]> <4i0fj8$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: dial-39.roch.millcomm.com
X-Newsreader: IBM NewsReader/2 v1.2

In <4i0fj8$[e-mail]>, [e-mail] (James Giles) writes:
>In 1968, Edsger Dijkstra wrote a letter to the _Communications_
>_of_the_ACM_ titled "Go To Statement Considered Harmful".  This
>paper has since been widely reprinted.  In 1974, Donald Knuth
>wrote a paper for _Computing_Surveys_ titled "Structured
>Programming with GOTO Statements".  This paper has also been
>widely reprinted.  These were not the first nor the only papers
>written on this subject, but to my mind, they should have been
>the last needed.  Anyone who argues this issue should first
>be required to prove he (or she) has read both these papers.
>Anyone who hasn't read these papers should be ignored out
>of hand.

Yep, I read those years ago (along with several titled "'Go To Statement
Considered Harmful' Considered Harmful", etc).  And I've got a copy of
the Dijkstra/Dahl/Hoare book around here somewhere.  What you said (in
the portion of your post that I've omitted) is certainly true for the
most part.  Whether or not you use GOTOs, and what sort of structuring
statements you use otherwise or besides is not really that important.

But you failed to spell out what IS important.  The critical factor to
consider here is how the structure of the program contributes to the
control of complexity.  First off, it must be understood that "toy"
examples are meaningless, since complexity isn't a factor at "toy"
scales.  Thus, the issues involved in the "GOTO controversy" can only be
fully appreciated by those who have been involved in "real" large
development complex projects -- projects where control of complexity was
a major consideration.

Once one is faced with this situation -- a project where complexity
threatens to make the situation unmanageable -- the desireable features
of a program structuring model become more apparent.  Foremost, one
would like to have a model that supports a sort of "nested black box"
approach.  Given a particular structuring construct (such as a DO-WHILE
block), one would like to be able to define the function of the
construct in a manner that's independent of its implementation.
Dijkstra and Hoare pushed this concept with preconditions and invariants
and the like.  The "invariants" are the key here -- the idea that the
actions of a construct can be described as preserving most of the state
of the system unchanged (even if the state changes temporarily within
the construct), while other parts of the state change in a well-defined
fashion (those changes being the "function" of the construct).

It's this clear separation of preserved state vs changed state that's
key:  With ordinary "non-structured" code it's easy for the two to get
intermingled -- for temporarily changed state to get entwined with the
changes that are to be a permanent result of the code segment under
consideration.

Proper use of structure prevents this entwinement.  A "structured" code
segment properly includes the statements at the front that make
temporary changes to the system state along with statements at the end
that undo those temporary changes.  And "proper" structure assures that
there is no way to enter the segment -- making the temporary changes --
without subsequently leaving the segment through the code that undoes
those temporary changes.

Proper structure also assures that the stated "function" of the segment
ALWAYS occurs.  (For this reason, the function statement may include an
error condition that is included as one of the possible outcomes.)

When these conditions are met, then it becomes possible to describe the
function of the code segment as a true "black box", and this in turn
allows one to ignore the internals of the segment when considering how
to "plug" segments together.  Since the same concepts can be applied to
larger and larger segments (composed of smaller segments), it becomes
possible to build applications of arbitrary complexity without losing
control.

Exactly what techniques are used to maintain the "invariants" depends on
personal preference, the skills of the programmers, etc.  If programmers
are sufficently skilled and also sufficiently self-controlled, plain old
assembly language will work pretty well (though it suffers the obvious
productivity problems).  If programmers are not highly skilled, or if
they can't be counted on to always exercise a high degree of
self-restraint, then a GOTO-less "structured" language will help
considerably (though not in itself assure a good outcome).

For my own part, I'd like to see more languages incorporate a
prolog/function/epilog block as the primary structuring construct.  TRY
blocks come close, but much more could be done.

Dan Hicks
http://www.millcomm.com/~danhicks/